JavaScript Module Federation Runtime Registry: Динамично откриване на модули

Module Federation, мощна функция, въведена от Webpack 5, революционизира начина, по който изграждаме и внедряваме JavaScript приложения, особено в областта на микрофронтендите. Тя позволява на различни приложения, изградени и внедрени независимо, да споделят код и функционалност по време на изпълнение. Докато статичните конфигурации на module federation са често срещани, истинската сила се крие в динамичното откриване на модули с помощта на Runtime Registry. Тази статия се задълбочава в концепцията за Runtime Registry за Module Federation, като изследва нейното внедряване, предимства и разширени случаи на употреба.

Какво е Runtime Registry?

В контекста на Module Federation, Runtime Registry действа като централен указател или услуга, която предоставя информация за наличните отдалечени модули. Вместо да кодирате твърдо местоположенията на отдалечените модули в конфигурацията на вашето приложение, вие отправяте заявка към регистъра по време на изпълнение, за да откриете и заредите необходимите модули. Този динамичен подход предлага няколко предимства:

• Разделяне: Приложенията са по-слабо свързани с конкретни версии или местоположения на отдалечени модули.
• Мащабируемост: По-лесно е да добавяте, премахвате или актуализирате отдалечени модули, без да се налага да внедрявате повторно консумиращите приложения.
• Адаптивност: Позволява динамични превключватели на функции и A/B тестване чрез обслужване на различни модули въз основа на условията по време на изпълнение.
• Устойчивост: Ако един отдалечен модул е недостъпен, регистърът може да предостави алтернативно местоположение или версия.

Защо да използвате Runtime Registry?

Помислете за голяма платформа за електронна търговия, съставена от няколко микрофронтенда, като например продуктов каталог, кошница за пазаруване и потребителски акаунти. Всеки микрофронтенд е разработен и внедрен независимо. Без Runtime Registry, всеки микрофронтенд ще трябва да знае точното местоположение и версия на всички споделени модули или компоненти, използвани от други микрофронтенди. Това създава тясна връзка и затруднява актуализациите. Например, актуализирането на споделен потребителски интерфейс компонент ще изисква повторно внедряване на всички микрофронтенди, които зависят от него.

С Runtime Registry, обаче, микрофронтендите просто отправят заявка към регистъра за местоположението и версията на необходимия компонент. След това регистърът може да предостави подходящата информация, което позволява на микрофронтендите да зареждат компонента динамично. Това разделяне позволява независими актуализации и намалява риска от счупване на промени.

Внедряване на Runtime Registry

Има няколко начина за внедряване на Runtime Registry, вариращи от прости JSON файлове до по-сложни услуги с възможности за версии и маршрутизация. Ето основен пример с помощта на прост JSON файл, хостван на уеб сървър:

1. Дефиниция на регистър (registry.json):

{
  "modules": {
    "@my-org/product-card": {
      "1.0.0": "https://cdn.example.com/product-card/1.0.0/remoteEntry.js",
      "1.1.0": "https://cdn.example.com/product-card/1.1.0/remoteEntry.js"
    },
    "@my-org/checkout-button": {
      "2.0.0": "https://cdn.example.com/checkout-button/2.0.0/remoteEntry.js"
    }
  }
}

Този JSON файл дефинира наличните модули и техните съответни URL адреси. Всеки модул има версии, сочещи към съответните `remoteEntry.js` файлове. Това позволява управление на версиите и лесно връщане назад, ако е необходимо.

2. Консумиращо приложение:

async function loadRemote(moduleName, version) {
  const registryUrl = 'https://example.com/registry.json';
  const response = await fetch(registryUrl);
  const registry = await response.json();

  const moduleInfo = registry.modules[moduleName];
  if (!moduleInfo) {
    throw new Error(`Module "${moduleName}" not found in registry.`);
  }

  const moduleUrl = moduleInfo[version];
  if (!moduleUrl) {
    throw new Error(`Version "${version}" for module "${moduleName}" not found.`);
  }

  return new Promise((resolve, reject) => {
    const script = document.createElement('script');
    script.src = moduleUrl;
    script.type = 'text/javascript';
    script.async = true;
    script.onload = () => {
      // Module is loaded, you can now access it using window[moduleName]
      resolve(window[moduleName]);
    };
    script.onerror = (error) => {
      console.error(`Error loading module ${moduleName} from ${moduleUrl}:`, error);
      reject(error);
    };
    document.head.appendChild(script);
  });
}

// Example usage:
loadRemote('@my-org/product-card', '1.0.0')
  .then((module) => {
    // Use the loaded module
    const ProductCard = module.ProductCard;
    const productCardInstance = new ProductCard({ name: 'Example Product' });
    document.getElementById('product-card-container').appendChild(productCardInstance.render());
  })
  .catch((error) => {
    console.error('Failed to load product card:', error);
  });

Този фрагмент от код демонстрира как да извлечете регистъра, да намерите желания модул и версия и динамично да заредите отдалечения запис. Той също така включва основна обработка на грешки.

3. Webpack конфигурация (отдалечено приложение):

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: '@my-org/product-card',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductCard': './src/ProductCard',
      },
      // shared: { ... }, // Shared dependencies
    }),
  ],
};

Това е стандартна Module Federation Webpack конфигурация за отдалеченото приложение, което излага компонента `ProductCard`. Ключовото тук е, че `filename` е `remoteEntry.js`, което е файлът, посочен в регистъра.

Разширени случаи на употреба

Простият пример по-горе може да бъде разширен, за да се справя с по-сложни сценарии:

Управление на версии

Регистърът може да съхранява множество версии на всеки модул, което позволява на консумиращите приложения да посочат желаната версия. Това е от решаващо значение за поддържане на съвместимост и позволяване на постепенни надстройки.

Пример: Регистърът може да съдържа информация за версията и консумиращото приложение може да поиска конкретна версия или диапазон от приемливи версии (напр. '>=1.0.0 <2.0.0'). След това регистърът може да върне подходящия URL адрес въз основа на заявката.

Маршрутизация и балансиране на натоварването

Регистърът може да действа като балансиращ натоварването, като насочва заявките към различни сървъри въз основа на наличността или географското местоположение. Това може да подобри производителността и надеждността.

Пример: Регистърът може да има множество URL адреси за един и същ модул, като всеки URL адрес сочи към различен CDN или сървър. След това регистърът може да използва алгоритъм за балансиране на натоварването, за да разпредели заявките между наличните сървъри.

Удостоверяване и оторизация

Регистърът може да прилага политики за удостоверяване и оторизация, като гарантира, че само оторизирани приложения имат достъп до конкретни модули. Това е от съществено значение за защита на чувствителен код и данни.

Пример: Регистърът може да изисква API ключ или токен за достъп до информацията за модула. Консумиращото приложение ще трябва да предостави правилните идентификационни данни, за да извлече URL адреса на модула.

Превключватели на функции

Регистърът може да се използва за внедряване на превключватели на функции, което ви позволява да активирате или деактивирате функции динамично, без да внедрявате повторно приложения. Това е полезно за A/B тестване и постепенно пускане на нови функции.

Пример: Регистърът може да има различни конфигурации за различни среди или потребителски групи. Въз основа на самоличността на потребителя или средата, регистърът може да върне различни URL адреси за един и същ модул, като ефективно активира или деактивира определени функции.

Динамична композиция на модули

Регистърът може да улесни динамичната композиция на модули, където модулите, заредени по време на изпълнение, зависят от условията на изпълнение или потребителските взаимодействия. Това позволява силно адаптивни и персонализирани приложения.

Пример: Въз основа на предпочитанията на потребителя или контекста на текущата страница, приложението може да поиска от регистъра подходящите модули за зареждане. Това позволява силно персонализирано потребителско изживяване.

Съображения и най-добри практики

Въпреки че Runtime Registry предлага значителни предимства, важно е да вземете предвид следните фактори:

• Производителност: Извличането на информацията от регистъра добавя допълнителна мрежова заявка. Помислете за кеширане на данните от регистъра, за да сведете до минимум латентността.
• Сложност: Внедряването и поддръжката на Runtime Registry добавя сложност към вашата архитектура. Внимателно оценете компромисите, преди да приемете този подход.
• Сигурност: Защитете регистъра от неоторизиран достъп и модификация. Внедрете подходящи механизми за удостоверяване и оторизация.
• Обработка на грешки: Внедрете стабилна обработка на грешки, за да се справите грациозно със случаите, когато регистърът е недостъпен или модул не може да бъде зареден.
• Мащабируемост: Уверете се, че регистърът може да се справи с очакваното натоварване и да се мащабира с нарастването на вашето приложение. Помислете за използване на разпределена база данни или кеширащ слой, за да подобрите производителността.
• Централизирано управление: Внедрете подходящи процеси за управление и управление на промените около регистъра, за да осигурите последователност и да избегнете конфликти.
• Мониторинг: Наблюдавайте производителността и наличността на регистъра, за да идентифицирате и разрешите проблемите проактивно.

Алтернативи на прост JSON регистър

Въпреки че простият JSON файл служи като добра отправна точка, често се изискват по-стабилни решения за производствени среди. Помислете за тези алтернативи:

• Персонализирана API услуга: Специализирана API услуга, изградена с Node.js, Python или Go, осигурява по-голяма гъвкавост и контрол върху логиката на регистъра. Това позволява функции като удостоверяване, оторизация, управление на версии и балансиране на натоварването.
• Инструменти за откриване на услуги (напр. Consul, etcd, ZooKeeper): Тези инструменти са предназначени за управление на конфигурации на услуги и осигуряване на динамично откриване на услуги. Те могат да се използват за съхранение и управление на данните от регистъра на module federation.
• Облачни услуги за конфигуриране (напр. AWS AppConfig, Azure App Configuration, Google Cloud Config): Тези услуги предоставят централизиран и мащабируем начин за управление на конфигурациите на приложения, включително регистъра на module federation.
• Съществуващи платформи за оркестрация на микроуслуги (напр. Kubernetes): Ако вече използвате платформа за оркестрация на микроуслуги, можете да използвате вградените функции за откриване на услуги и управление на конфигурации за регистъра на module federation.

Пример: Глобална платформа за електронна търговия

Представете си глобална платформа за електронна търговия с магазини в множество държави. Всяка държава може да има различни продуктови каталози, методи на плащане и опции за доставка. Runtime Registry може да се използва за динамично зареждане на подходящите модули въз основа на местоположението и предпочитанията на потребителя.

Например, потребител в Германия може да види продуктов каталог с немски описания и цени в евро, докато потребител в Япония може да види продуктов каталог с японски описания и цени в йени. Runtime Registry ще определи кои модули да се заредят въз основа на местоположението и предпочитанията на потребителя.

Освен това, модулът за плащане може да бъде динамично избран въз основа на местоположението на потребителя. Потребителите в Германия може да видят опции за плащане с PayPal или кредитна карта, докато потребителите в Япония може да видят опции за плащане с кредитна карта или плащане в магазин за удобства.

Това ниво на динамично персонализиране е трудно да се постигне без Runtime Registry.

Заключение

Runtime Registry е мощен инструмент за разрешаване на динамично откриване на модули в JavaScript Module Federation. Той предлага няколко предимства, включително разделяне, мащабируемост, адаптивност и устойчивост. Въпреки че внедряването на Runtime Registry добавя сложност към вашата архитектура, предимствата често надвишават разходите, особено за големи и сложни приложения. Като внимателно обмислите факторите, посочени в тази статия, можете успешно да внедрите Runtime Registry и да отключите пълния потенциал на Module Federation.

Тъй като архитектурата на микрофронтендите продължава да се развива, Runtime Registry ще играе все по-важна роля за разрешаване на мащабируеми и адаптивни уеб приложения. Прегърнете тази технология и изградете бъдещето на фронтенд разработката.